home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 5⁄4⁄90 / 1222-Document Toolbox-Apr90 < prev    next >
Encoding:
Text File  |  1990-05-04  |  3.3 KB  |  72 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  LOOMIS       to GUITTET1
  2.  
  3. Item forwarded  by  LOOMIS       to COWSAR1      PLUMMER1     REKIETA1
  4.  
  5. Item forwarded  by  D2303        to AUTOMATION
  6.  
  7. Item    1435256                         30-April-90        17:37PDT
  8.  
  9. From:   AFTERHOURS                      After Hours SW,Richard Wolpert,PRT
  10.  
  11. To:     D5295                           Reseach SW Design, D Goldman,PRT
  12.  
  13. cc:     MACAPP.TECH$                    MacApp Technical
  14.  
  15. Sub:    Document Toolbox
  16.  
  17.     TO: D5295
  18.     FR: AFTERHOURS
  19.     CC: MACAPP.TECH$
  20.     RE: Document ToolBox
  21.  
  22. I remember reading a letter to Tog in Apple Direct (??? I think that's where)
  23. about the modality of MultiFinder.   MultiFinder puts the user in a sort of
  24. large modal state, either word processing, graphics, spreadsheets, etc...
  25.  
  26. The writer continued to make the point that this goes directly against the
  27. grain of the Macintosh, and that MultiFinder should be centered around
  28. documents, not applications.
  29.  
  30. This comment really hit home for me, both from a users and from a programmers
  31. standpoint.  The column then went on to explain the history of Multifinder, why
  32. MultiFinder evolved as it did, the downfalls of MultiFinder, and that, yes,
  33. this 'document-based' OS was a much better, and less modal, metaphore.
  34.  
  35. Your link hit our future right on the nose.   We should be developing
  36. applications that are more specific and less all-encompassing.  For me, System
  37. 7 and IAC promises hundreds of thousands of possibilities not thought of
  38. before.
  39.  
  40. To start this new metaphor, companies that already sell several types of
  41. applications could (should) develop a document manager application, and revamp
  42. their product line to work under this new document OS.  If software developers
  43. agreed to standard IAC calls for word processing, spreadsheets, drawing and
  44. painting programs, databases, etc... then we could all develop specific
  45. applications, and like you say, not have to worry about not giving th euser
  46. enough features.    Then any user could buy a document engine, and mix and
  47. match appliation toolboxes to their hearts content.
  48.  
  49. My only concern is that, for every document-based application, I can also think
  50. of a non document-based application such as communications, games, real-time
  51. analysis, video, music composition, etc.   So such a new metaphor would have to
  52. be a sub-sustem to the Mac OS, and thus perhaps just another app using IAC to
  53. communicate with other toolbox programs (may I offer the term "application
  54. engines" as an alternative) and the Mac toolboxes.  This would be your Document
  55. Manager.   Perhaps Apple should write the document manager application, thus
  56. ensuring its uniform implementation to the user AND the programmer.  Perhaps it
  57. should be a replacement to MultiFinder.  Perhaps it would be a Document Toolbox
  58. set, which is part of the OS.  :)
  59.  
  60. As you say, MacApp is an excellent choice for developing such a system.
  61. Standard objects and features in MacApp could provide IAC support (as well as
  62. publish/subscribe support) once they were developed and refined.  With IAC as a
  63. standard in MacApp, we could all take advantage of System 7's capabilites and
  64. develop document-based sub-evironments.
  65.  
  66. In conclusion, I'm all for your idea that MacApp should play a big part in this
  67. new metaphor.  I'd like to hear more views as well.
  68.  
  69. Dan Cooley
  70. After Hours Software
  71.  
  72.